

	2/25/06

	Here, I am going to make some notes and observations obseravation on how to
	calculate the path velocity of the NURBS generated trajectory "on the fly".

	For each NURB segment, a total distance of the curve is given. (For now
	I will assume the knot vector values provided by OpenNURBS is accurate
	and will be the value used for path length. If I discover this to be
	contradictory, I will write my own algorythm using the "Guassian Quadrature"
	technique I outlined in the main notes to this project).

	The technique to control path speed will envolve the master (or the NURBS
	server) determining the derivative of the X, Y, and Z points as a function
	of the current reference variable. 

	A simple calculation of (X'**2 + Y'**2 + Z'**2)**.5 will produce the
	path speed at the current points X, Y, and Z'.

	This result will be compared with the desired vector velocity, which is
	simply detemined by dividing the  maximum knot value by the total 
	time for which the curve is to be generated.

	The reference will be adjusted interative based on this comparison.
	(This is the idea I found in the original NURBS analysis in document
	 "MovingAtConstantSpeed.pdf").

	The NURBS profile will most likely be made up of a multatude of segments
	each with different knot vector that are connected (tangent) to each
	other. Some of the NURBS knots will be non-uniform.

	The algorythm above should be able to compensate for these non-uniform vectors 
	without too much problem.

	The only thing that will have to be done is to determine the additional
	"guess" for the reference (this is outlined in "MovingAtConstantSpeed.pdf".
	This will probably require a large mount of interations to the algorythm.

	However, this can be done before execution of the first point. There after, the
	change in path direction should be relatively small from point to point,
	allowing the algorythm to keep up (even when traversing between consequiative
	segments).

	Consequitive segments should be tangent at the joining points. However, the
	path lengths may not necessarily be the same.

	The reference will need to be rescaled at each transition point. This should
	be straight forward. However, how this effects the "constant speed" generation
	algorythm is an unknown at this point.

	One additional point before moving on. The "MovingAtConstantSpeed.pdf" code
	describes a simple "integral" control. Will we benifaet by implementing
	a "porportional-integral" control?.


	** Actual calculation of the derivative of the B-Spline **

	I note two documents I copied into this directory ("B-splines.htm" and 	
	"Derivatives of a B-spline Curve.htm"), both copied in from the 
	original NURBS analysis ("B-Splines (Original Project)").

	I located a third document "prochazhova.pdf" describing the derivitive
	of the NURBS equation.

	Comparing "B-splines.htm" with the description of the derivative of the
	equation in "Derivatives of a B-spline Curve.htm", I see an abiquity
	in the defintion of "order" and "degree". However, I think both
	aggree with each other.

	Using the nomencature in "B-splines.htm" to prove the validy of 
	"Derivatives of a B-spline Curve.htm" based on an NURBS of "order = 2":

	N'i,2(t) = [1/(ti+1 - ti)]*Ni,1(t) + [(t - ti)/(ti+1 - ti)]*N'i,1(t) +
		     [-1/(ti+2 - ti+1)]*Ni,1(t) + [(t - ti)/(ti+2 - ti+1)]*N'i+1,1(t) 
		     
       
	for k = 2, N'i,1(t) and N'i+1,1(t) => 0

	thus,
		
	N'i,2(t) = [1/(ti+1 - ti)]*Ni,1(t) - [1/(ti+2 - ti+1)]*Ni,1(t)

		comparing to form N'i,p(u) in "Derivatives of a B-spline Curve.htm", 
				
				p = k - 1 => 1  which aggrees


	2/25/06 (Addendium)

	The generalized derivation and proof of the Derivative of a B-Spline (for any "k")
	is provided in "prochazhova.pdf" mentioned above.

	I review the entire document. The proof is straight forward.
